Doc 1776/open banking partner documentation on docsswanio - #641
Doc 1776/open banking partner documentation on docsswanio#641max-koro wants to merge 11 commits into
Conversation
✅ Deploy Preview for incomparable-tiramisu-91a96a ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
racene-swan
left a comment
There was a problem hiding this comment.
Hey! Great work pulling these together - some edits to improve the readability.
|
|
||
| :::note All or nothing | ||
| The consent flow does not currently allow users to select a subset of accounts; it is all or nothing. | ||
| This is a known limitation of the current consent flow. |
There was a problem hiding this comment.
Should we be calling this out as a limitation? Isn't just stating the behaviour enough?
|
|
||
| **Solutions**: | ||
|
|
||
| - **Option 1, try with the correct phone number**: authenticate again using the professional phone number linked to the Swan account. |
There was a problem hiding this comment.
| - **Option 1, try with the correct phone number**: authenticate again using the professional phone number linked to the Swan account. | |
| - **Option 1, try with the correct phone number**: authenticate again using the phone number linked to the Swan account. |
| | `reference` | `remittance_information.structured` | Structured payment reference. | | ||
| | `paymentId` | `extra.additional_information` | Not the same as the transaction ID. A payment can have multiple transactions, for example for fees. | | ||
| | For SCTs: `creditor.name`. Else if user is on the credit side: `account.holder.info.name`. Else: `counterparty`. | `creditor_details.name` | Creditor or recipient name. | | ||
| | `creditor.IBAN` | `creditor_details.account.iban` | Optional. Always served when the transaction is a SEPA Credit Transfer or the end user is on the credit side. | |
There was a problem hiding this comment.
| | `creditor.IBAN` | `creditor_details.account.iban` | Optional. Always served when the transaction is a SEPA Credit Transfer or the end user is on the credit side. | | |
| | `creditor.IBAN` | `creditor_details.account.iban` | Optional. Always served when the transaction is a SEPA Credit Transfer or the user is on the credit side. | |
Currently use 'user' and 'end user' interchangeably throughout the content. Update to user across everything.
|
|
||
| ### Consent revocation {#consent-revocation} | ||
|
|
||
| The user consent token can be revoked by the TPP, following a request from the end user. |
There was a problem hiding this comment.
| The user consent token can be revoked by the TPP, following a request from the end user. | |
| Users can ask their TPP to revoke the consent token. Swan can't revoke it directly. |
Active
|
|
||
| ### Connected TPPs {#ecosystem-tpps} | ||
|
|
||
| :::note |
There was a problem hiding this comment.
This needs a custom title - all call-outs need one.
| @@ -0,0 +1,2 @@ | |||
| A 180-day token granting a Third-Party Provider Open Banking access to a user's Swan account. | |||
| The consent token is issued after the user completes Strong Customer Authentication and must be renewed every 180 days, as required by PSD2. | |||
There was a problem hiding this comment.
| The consent token is issued after the user completes Strong Customer Authentication and must be renewed every 180 days, as required by PSD2. | |
| Swan issues the consent token once the user completes Strong Customer Authentication and must be renewed every 180 days, as required by PSD2. |
| @@ -0,0 +1,2 @@ | |||
| A Third-Party Provider authorized to access account information on behalf of a user. | |||
| Account Information Service Providers (AISPs) can read account balances and transaction history after the user grants explicit consent. | |||
There was a problem hiding this comment.
| Account Information Service Providers (AISPs) can read account balances and transaction history after the user grants explicit consent. | |
| Account Information Service Providers (AISPs) can read account balances and transaction history once the user grants explicit consent. |
| @@ -0,0 +1,2 @@ | |||
| A PSD2 requirement that protects sensitive banking actions with two independent authentication factors. | |||
| Strong Customer Authentication (SCA) combines something the user has (such as their phone) with something they know or are (such as a passcode or biometric), and is required for Open Banking consent and payment confirmation. | |||
There was a problem hiding this comment.
| Strong Customer Authentication (SCA) combines something the user has (such as their phone) with something they know or are (such as a passcode or biometric), and is required for Open Banking consent and payment confirmation. | |
| Strong Customer Authentication (SCA) combines something the user has (such as their phone) with something they know or are (such as a passcode or biometric). PSD2 requires SCA for Open Banking consent and payment confirmation. |
Split for readability.
| Salt Edge reviews the application and, if approved, grants access to their platform and Swan's PSD2 API. | ||
| Testing happens in Salt Edge's own sandbox, not in Swan's Sandbox environment. | ||
|
|
||
| ## Key concepts {#key-concepts} |
There was a problem hiding this comment.
These are already at the top of the page - is it necessary to repeat?
| - **Failed payment**: a [`RejectedReasonCode`](https://api-reference.swan.io/enums/rejected-reason-code). | ||
| ::: | ||
|
|
||
| ## FAQ {#faq} |
There was a problem hiding this comment.
This is misplaced - we don't do FAQs in our content. Update the heading to read more like the question asked.
No description provided.